update bikehorn guide to modern standards#644
Conversation
Co-authored-by: Connor Huffine <chuffine@gmail.com>
RemFexxel
left a comment
RemFexxel
left a comment
There was a problem hiding this comment.
Nitpicks, but this overall looks fine to me. 👍
Co-authored-by: Rem <Remfexxel@pm.me>
Fildrance
left a comment
Fildrance
left a comment
There was a problem hiding this comment.
Few ideas for improvements.
Used guide, it works, new class references are valid.
I propose fixing stuff i found and merging, then asking peeps triagers to try collect feedback on it from newcomers.
| ### Entities | ||
|
|
||
| Each item in game is represented by an *entity*. Players, bananas, stun batons, are all represented by entities. An entity is represented by an integer. No two entities share the same integer representation. | ||
| Each object in-game is represented by an *entity*. Players, bananas, stun batons, audio sources, or even more abstract concepts like game rules or objectives are all represented by entities. An entity is represented by an integer. No two entities share the same integer representation. |
There was a problem hiding this comment.
i'd propose to change wording about ids a little bit:
Each entity upon creation is automatically assigned a unique integer identifier, and no two entities can share same.
I do understand that talking about NetEntityId and EntityUid here is not good idea, thats for sure. So i guess even mentioning EntityUid, which we use most of the time, would probably be incorrect? Not sure. But if you think that its okay to mention it here - we probably can mention it as something like that (probably wrap in separate panel or expander )
Each entity upon creation is automatically assigned a unique integer identifier, and no two entities can share same. In code we usually reference game objects by id using EntityUid type, or wrappers like Entity<...> which include such id.
| ℹ️ Info |
|---|
| With client-server approach comes networking problems, details about that are described on separate page (https://docs.spacestation14.com/en/robust-toolbox/netcode/net-entities.html?) and are more advanced topic, not required for understanding to finish this guide. |
| Entity systems implement behavior by defining *event handlers* or by implementing a per-tick *update* method. | ||
|
|
||
| As an another example, consider the `FoodComponent`. A programmer might make `EatingSystem` to handle eating food. `EatingSystem` listens to the `OnUseInHand` event - whenever `OnUseInHand` is heard/triggered, `EatingSystem` checks if there is a `FoodComponent` in the object that was used. If there is, then it lowers the value of `nutritionLeft` and plays a munching sound. | ||
| As an another example, consider the `EdibleComponent`. A programmer might make `IngestionSystem` to handle eating food. `IngestionSystem` listens to the `UseInHandEvent` - whenever `UseInHandEvent` is heard/triggered, `IngestionSystem` checks if there is a `EdibleComponent` in the object that was used. If there is, then it lowers the value of the nutrition inside the entity and plays a munching sound. |
There was a problem hiding this comment.
Probably worth rephrasing last part by saying
then it lowers the value of the nutrition inside the entity (by changing values on EdibleComponent that is attached to it), and plays a munching sound.
I am not 100% sold on this, because clean-li-ness is quite critical for beginner guide, and additional complexity by this phrase in braces could be not justified, but thats my proposal at least.
|
|
||
| SS14 uses a system we call **prototypes**. These are "entity presets", essentially. They are similar to *prefabs* in Unity, or a subtype of `/obj` or `/mob` in BYOND. | ||
|
|
||
| Entity prototypes define *which components are on the entity, and what data those components hold*. It also defines basic data like the entity's name, description, and prototype ID (used to spawn it). |
There was a problem hiding this comment.
probably worth detalization
Entity prototypes define which components are on the entity upon initialization, and what data those components hold at initialization time.
Although i am not sure on using word 'initialization' because we have such step in component lifetime and it could be misunderstood that it is only works while component is in initialization stage? But that doesnt sound like a beginner mistake.
| ``` | ||
|
|
||
| All you need to do to create a field that can be modified in YAML is to add the `[DataField]` attribute, which holds the name of the field, and give it a default value, in this case `string.Empty`. Now, we can add our sound to our bike horn prototype: | ||
| All you need to do to create a field that can be modified in YAML is to add the `[DataField]` attribute, and give it a default value, in this case `string.Empty`. Now, we can add our sound to our bike horn prototype: |
There was a problem hiding this comment.
I am not sure its valuable to say about string.Empty here - maybe omit it?
| ``` | ||
|
|
||
| You'll notice that here, our system inherits from `EntitySystem`. This automatically registers it as a proper EntitySystem in the game and allows us to use some useful dependencies and override some methods to add behavior. | ||
| You'll notice that here, our system inherits from `EntitySystem`. This automatically registers it as a proper `EntitySystem` in the game and allows us to use some useful dependencies and override some methods to add behavior. |
There was a problem hiding this comment.
there is a small mess of using 'code' formatting:
in this line it is used now for both existing in code type EntitySystem - which is correct,
and for term EntitySystem - which is a bit odd.
4 participants
A lot of stuff referenced was outdated.
Also added namespace imports since I've seen that confuse a lot of new coders.